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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The following are the related appeals, interferences, and judicial proceedings known to 
the examiner which may be related to, directly affect or be directly affected by or have a 
bearing on the Board's decision in the pending appeal: 
Copending US application 10/046,940 is currently under appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

US 6,31 1 ,321 to Agnihotri et al. 1 0/2001 

"Common Information Model (CIM) Specification v. .2.2" 5/1999 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
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Claims 1, 3-8, 10-15, 17-21 and 25 are rejected under 35 U.S.C. 102(e) as being 
anticipated by US 6,31 1 ,321 to Agnihotri et al. (Agnihotri). 

Claims 2, 9, 16 and 22-24 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over US 6,31 1,321 to Agnihotri et al. (Agnihotri) in view of "Common Information Model 
(CIM) Specification v. 2.2" (CIM) 

Claims 1, 3-8, 10-15, 17-21 and 25 are rejected under 35 U.S.C. 102(e) as being 
anticipated by US 6,311,321 to Agnihotri et al. (Agnihotri). 
Regarding Claims 1, 8 and 15: Agnihotri discloses receiving one or more console 
identifiers, each of the console identifiers corresponding to one of the management 
consoles (col. 5, lines 3-7 'provides the user the option to select one console'); 
retrieving one or more plug-in code files, each of the plug-in code files derived from the 
management data (col. 4, lines 50-55 'applet components') and each adapted to 
interface with one of the management consoles (col. 4, lines 50-55 'specific to the 
Enterprise management console'); retrieving one or more display panel files derived 
from the management data (col. 5, lines 10-12 The install file may contain a ... image 
file for graphical representation on the console'); and writing the plug-in code files and 
the display panels to a distribution medium (col. 4, lines 32-35 'a software module 
provided on a tangible medium'). 

As discussed in more detail in the Arguments section of this document, any application 
written to manage a device is necessarily 'derived from management data' related to 
that device. While it is acknowledged that Agnihotri does not explicitly disclose a 
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derivation process, to the extent recited in the claims, such a process, is inherent in the 
nature of Agnihotri's 'applet'. 

Regarding Claims 3, 10 and 17: The rejection of claims 1, 8 and 15 are incorporated 
respectively; further Agnihotri discloses retrieving one or more translation files derived 
from the management data (col. 4, 50-55 'class object definitions'), each of the 
translation files corresponding to at least one national language (col. 5, lines 43-46 
'console information such as ... language'); and writing the translation files to the 
distribution medium (col. 4, lines 32-35 'a software module provided on a tangible 
medium'). 

Regarding Claims 4, 11 and 18: The rejection of claims 1, 8 and 15 are incorporated 
respectively; further Agnihotri discloses that each of the display panel files is adapted to 
operate with a plurality of the management consoles (col. 4, lines 58-63 'generic 
interface'). 

Also see Fig. 3, where as discussed in the Arguments section, the plurality of console 
install DLLs 216A-216C represent an adaptation mechanism contained in the "Install 
framework 212" which is used to 'integrate the component (applet)' (col. 5, lines 8-10 
'the component (applet) to be installed') including the associated 'image file for 
graphical representation on the console' (col. 5, lines 10-12) 

Regarding Claims 5, 12 and 19: The rejection of claims 1, 8 and 15 are incorporated 
respectively; further Agnihotri discloses retrieving one or more plug-in runtime 
algorithms (col. 7, lines 3-8 'interface COM objects'), each of the algorithms 
corresponding to one of the console identifiers (col. 7, lines 3-8 'console specific 
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commands'); generating a console plug-in code file for each of the console identifiers 
(col. 7, lines 3-8 'COM objects ... translate instructions ... into console specific 
commands'; Fig. 4); the compiling resulting in an executable entity adapted to interface 
with the management console corresponding to the console identifier (col. 6, lines 49-53 
'a comprehensive generic interface to existing Enterprise management consoles') and 
inherently discloses compiling each of the generated console plug-in files (Fig. 4). 
Additionally, as discussed in more detail in the arguments section, it can be seen from 
Agnihotri's Fig. 4 that the 'MConsole' and 'COM objects' are linked thereby 'generating 
a plug-in code file'. Additionally such a step would first require that the objects (COM 
objects in particular) be retrieved from whatever storage medium they were residing on.. 
Further, Fig. 4 shows that these objects are in DLL and COM formats, respectively, and 
thus must have been compiled to produce executable objects. 
Regarding Claims 6, 13 and 20: The rejection of claims 1 , 8 and 15 are incorporated 
respectively; further Agnihotri discloses loading the distribution medium into a computer 
system (col. 4, lines 47-48 'install module'); displaying a name corresponding to each of 
the management consoles in a selection display (col. 5, lines 3-7 'provides the user the 
option to select one console'); receiving one or more selections from a user, each of the 
selections corresponding to one of the management consoles (col. 5, lines 3-7 'provides 
the user the option to select one console'); copying the plug-in code files corresponding 
to the selected management consoles from the distribution medium to a nonvolatile 
storage device accessible by the computer system (col. 5, lines 15-18 Install the 
component'); copying the display panel files from the distribution medium to a 
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nonvolatile storage device accessible by the computer system (col. 5, lines 15-18 'may 
proceed to install the component'); and registering each of the plug-in code files with 
one or more installed management consoles (col. 5, lines 15-18 'and make appropriate 
updates to the console to integrate the component'), wherein the installed management 
consoles are installed on the computer system (col. 5, lines 5-6 'consoles are installed 
at a host system'). 

Regarding Claims 7, 14 and 21: The rejection of claims 6, 13 and 20 are incorporated 
respectively; further Agnihotri discloses invoking one of the installed management 
consoles (col. 5, lines 15-18 'and make appropriate updates to the console to integrate 
the component'); receiving a console selection from a user (col. 5, lines 3-7 'provides 
the user the option to select one console'); and displaying a display panel 
corresponding to one of the display panel files in response to the received selection 
(col. 5, lines 10-12 'an image file for graphical representation on the console'). 
Regarding Claim 25: Agnihotri discloses a computer program product stored on a 
computer operable medium for packaging management data adapted to interoperate 
with one or more management consoles, said computer program product comprising: 
means for receiving one or more console identifiers, each of the console identifiers 
corresponding to one of the management consoles (col. 5, lines 3-7 'provides the user 
the option to select one console'); means for retrieving one or more plug-in code files 
(col. 4, lines 50-55 'applet components'), each of the plug-in code files derived from the 
management data and each adapted to interface with one of the management consoles 
(col. 4, lines 50-55 'specific to the Enterprise management console'); means for 
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retrieving one or more display panel files derived from the management data (col. 5, 
lines 10-12 The install file may contain a ... image file for graphical representation on 
the console 7 ); means for retrieving one or more translation files derived from the 
management data (col. 4, 50-55 'class object definitions'), each of the translation files 
corresponding to at least one national language (col. 5, lines 43-46 'console information 
such as ... language'); and means for writing the translation files the plug-in code files 
and the display panels to a distribution medium (col. 4, lines 32-35 'a software module 
provided on a tangible medium'). 

Claims 2, 9, 16 and 22-24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over US 6,311,321 to Agnihotri et al. (Agnihotri) in view of "Common 
Information Model (CIM) Specification v. 2.2" (CIM). 

Regarding Claims 2, 9 and 16: The rejection of claims 1, 8 and 15 are incorporated 
respectively; further Agnihotri discloses the use of non-console specific management 
applications (col. 6, line 56), but does not disclose that the definition is a common 
information model managed object format. 

CIM teaches a common information model managed object format file (pg. 1, ch. 1.1 
'management schemas') in an analogous art for the purpose of providing a 'conceptual 
framework ... to organize the available information about the managed environment' 
(pg. 1,ch. 1.1). 

It would have been obvious to a person of ordinary skill in the art at the time of the 
invention to model the 'device management applications' disclosed in Agnihotri (col. 6, 
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line 56) using the CIM management schema because one of ordinary skill in the art 
would have been motivated to model the management information using a method 
which allows for ease of development and reuse (CIM Ch. 1 Introduction and Overview 
'Ideally, information used to perform tasks is organized or structured to allow disparate 
groups of people to use it') 

Regarding Claim 22: Agnihotri discloses a method of packaging management data 
adapted to interoperate with one or more management consoles, said method 
comprising: receiving one or more console identifiers, each of the console identifiers 
corresponding to one of the management consoles (col. 5, lines 3-7 'provides the user 
the option to select one console'); retrieving one or more plug-in code files, each of the 
plug-in code files derived from the management data and each adapted to interface with 
one of the management consoles (col. 4, lines 50-55 'applet components'); retrieving 
one or more display panel files derived from the management data (col. 5, lines 10-12 
The install file may contain a ... image file for graphical representation on the console'); 
retrieving one or more translation files derived from the management data, each of the 
translation files corresponding to at least one national language (col. 5, lines 43-46 
'console information such as ... language'); and writing the translation files, the plug-in 
code files and the display panels to a distribution medium (col. 4, lines 32-35 'a software 
module provided on a tangible medium'). Agnihotri does not disclose that the 
management data includes a common information model managed object format file, 
but discloses the use of non-console specific management applications (col. 6, line 56). 
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CIM teaches a common information model managed object format file (pg. 1 , ch. 1.1 
'management schemas') in an analogous art for the purpose of providing a 'conceptual 
framework ... to organize the available information about the managed environment'. 
It would have been obvious to a person of ordinary skill in the art at the time of the 
invention to model the 'device management applications 7 disclosed in Agnihotri (col. 6, 
line 56) using the CIM management schema because one of ordinary skill in the art 
would have been motivated to model the management information using a method 
which allows for ease of development and reuse (CIM Ch. 1 Introduction and Overview 
'Ideally, information used to perform tasks is organized or structured to allow disparate 
groups of people to use it). 

Regarding Claim 23: Agnihotri discloses a method of packaging management data 
adapted to interoperate with one or more management consoles, said method 
comprising: receiving one or more console identifiers, each of the console identifiers 
corresponding to one of the management consoles (col. 5, lines 3-7 'provides the user 
the option to select one console'); retrieving one or more plug-in code files, each of the 
plug-in code files derived from the management data and each adapted to interface with 
one of the management consoles (col. 4, lines 50-55 'applet components'); retrieving » 
one or more display panel files derived from the management data (col. 5, lines 10-12 
The install file may contain a ... image file for graphical representation on the console'); 
retrieving one or more translation files derived from the management data, each of the 
translation files corresponding to at least one national language (col. 5, lines 43-46 
'console information such as ... language'); retrieving one or more plug-in runtime 
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algorithms, each of the algorithms corresponding to one of the console identifiers (col. 
6, lines 55-60 'device management applications'); generating a console plug-in code file 
for each of the console identifiers (col. 7, lines 3-8 'COM objects ... translate 
instructions ... into console specific commands'); compiling each of the generated 
console plug-in files, the compiling resulting in an executable entity adapted to interface 
with the management console corresponding to the console identifier (col. 6, lines 62-65 
The console libraries'); writing the translation files, the compiled plug-in code files and 
the display panels to a distribution medium (col. 4, lines 32-35 'a software module 
provided on a tangible medium'). Agnihotri does not disclose that the management data 
includes a common information model managed object format file, but discloses the use 
of non-console specific management applications (col. 6, line 56). 
CIM teaches a common information model managed object format file (pg. 1, ch. 1.1 
'management schemas') in an analogous art for the purpose of providing a 'conceptual 
framework ... to organize the available information about the managed environment'. 
It would have been obvious to a person of ordinary skill in the art at the time of the 
invention to model the 'device management applications' disclosed in Agnihotri (col. 6, 
line 56) using the CIM management schema because one of ordinary skill in the art 
would have been motivated to model the management information using a method 
which allows for ease of development and reuse (CIM Ch. 1 Introduction and Overview 
'Ideally, information used to perform tasks is organized or structured to allow disparate 
groups of people to use it'). 
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Regarding Claim 24: Agnihotri discloses an information handling system comprising: 
one or more processors; a memory accessible by the processors; a nonvolatile storage 
area accessible by the processors; and a packaging tool for packaging management 
data adapted to interoperate with one or more management consoles, the packaging 
tool including: input logic for receiving one or more console identifiers, each of the 
console identifiers corresponding to one of the management consoles (col. 5, lines 3-7 
'provides the user the option to select one console'); retrieval logic for retrieving one or 
more plug-in code files, each of the plug-in code files derived from the management 
data and each adapted to interface with one of the management consoles (col. 4, lines 
50-55 'applet components'); retrieval logic for retrieving one or more plug-in runtime 
algorithms, each of the algorithms corresponding to one of the console identifiers (col. 
6, lines 55-60 'device management applications'); code generation logic for generating a 
console plug-in code file for each of the console identifiers (col. 7, lines 3-8 'COM 
objects ... translate instructions ... into console specific commands'); and compiler logic 
for compiling each of the generated console plug-in files, the compiling resulting in an 
executable entity adapted to interface with the management console corresponding to 
the console identifier (col. 6, lines 62-65 The console libraries'); retrieval logic for 
retrieving one or more display panel files derived from the management data (col. 5, 
lines 10-12 The install file may contain a ... image file for graphical representation on 
the console'); output logic for writing the compiled plug-in code files and the display 
panels to a distribution medium (col. 4, lines 32-35 'a software module provided on a 
tangible medium'). Agnihotri does not disclose that the management data includes a 
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common information model managed object format file, but discloses the use of non- 
console specific management applications (col. 6, line 56). 

CIM teaches a common information model managed object format file (pg. 1, ch. 1.1 
'management schemas') in an analogous art for the purpose of providing a 'conceptual 
framework ... to organize the available information about the managed environment'. 
It would have been obvious to a person of ordinary skill in the art at the time of the 
invention to model the 'device management applications' disclosed in Agnihotri (col. 6, 
line 56) using the CIM management schema because one of ordinary skill in the art 
would have been motivated to model the management information using a method 
which allows for ease of development and reuse (CIM Ch. 1 Introduction and Overview 
'Ideally, information used to perform tasks is organized or structured to allow disparate 
groups of people to use it'). 

(10) Response to Argument 

L 35 U.S.C. 102, Anticipation 

1. Independent Claims 1, 8, 15 and 25 

Starting in the last paragraph on pg. 8, Appellant states: 

The rejected independent claims ... all recite "plug-in code files derived from the 
management data" and "display panel files derived from the management data" ... 
These features are not taught or suggested by Agnihotri. While the examiner has 
cited various excerpts from Agnihotri that the Examiner argues teach these claim 
elements, Agnihotri fails to teach or otherwise describe or suggest the origin of the 
"applet components" and "install interface" the Examiner refers to. 

Examiner respectfully disagrees. As stated in previously, the language of the claims 

places no limitations on the terms 'management data' and 'derived'. Further, it is noted 
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that the 'means plus function' language of claims 15 and 25 does not apply to the 
derivation aspect of the respective limitations. Consequently the scope of the claims is 
very broad. 

With that in mind Agnihotri's discloses 'device management applications (applets)' (col. 
3, lines 24-29) and that applets have associated display files (col. 5, lines 8-12 'an 
install file for the component (applet) ... may contain ... an image file for graphical 
representation on the console'). 

Any application written to manage a device is necessarily 'derived from management 

data' related to that device. In other words, the application would be unable to interface 

with the device to perform management functions applicable to that device if it were 

written without knowledge of (not derived from) the management functions the device is 

capable of (Management Data). While it is acknowledged that Agnihotri does not 

explicitly disclose a derivation process, to the extent recited in the claims, such a 

process is inherent in the nature of Agnihotri's 'applet'. 

In the paragraph bridging pp. 9 and 10 Appellant states: 

The present invention, on the other hand, is specifically directed to the derivation of 
plug-in code and display panels from management data. In a preferred embodiment, 
these plug-in code files and display panel files are specifically derived from 
management definition objects, such as from an MOF (Management Object Format) 
file 

With the exception of claims 2, 9, 16 and 22-24 which were rejected as unpatentable 
over Agnihotri in view of CIM, Appellant's asserted limitations (derivation of plug-in code 
files from an MOF) do not appear in the claims. Further, claims 2, 9, 16 and 22-24, only 
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recite 'the management data including a common information model and do not recite 

any limitation specifically regarding the process of derivation. 

In the last paragraph on pg. 10 Appellant states: 

In addition, with respect to independent claim 25, Agnihotri fails to teach or suggest 
the claimed feature of "retrieving one or more translation files derived from the 
management data, each of the translation files corresponding to at least one national 
language" ... Although the Examiner cites an excerpt from Agnihotri that makes a 
passing reference to "language," the excerpt makes no mention of retrieving any 
translation files corresponding to any national language. In fact, from the context, it 
appears that by "language," Agnihotri is referring to a computer programming 
language, such as C or Pascal, rather than a "national" or "nature" language use for 
human communication, (emphasis in original) 

Examiner respectfully disagrees. The relevant disclosure from Agnihotri is reproduced 

below. 

The Install Interface DLL 214 may store generic instruction sets (i.e., interface 
programs) for supporting the installation process, including providing console 
information such as installation directory, language. Console version, etc. Individual 
instruction sets (in bold print) and textual comments may be written in any of the C- 
family (e.g., C or C++) code language. However, other program languages included 
in the non-exhaustive list of Basic and Pascal may also be used. 

The cited section of Agnihotri is discussing an "Install Interface", and the reference to 

"language" is presented as "console information" "for supporting the installation 

process". Thus it can be seen that language' in this context refers to the 'national 

language' displayed on the 'console' and . Further, Agnihotri's reference to computer 

programming languages is discussing the implementation of the 'generic instruction 

sets' and not a console language. 



2. Dependent Claims Rejected Under 102 



2a. Dependent Claims 3. 10 and 17 
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At the bottom of pg. 1 1 , Appellant presents arguments regarding claims 3, 10 and 17 
which are essentially the same as those discussed above with regard to claim 25, and 
consequently are not addressed here. 
2b Dependent Claims 4. 11 and 18 

Starting in the 2 nd to last paragraph on pg. 12 Appellant states: 

Agnihotri does not teach or suggest a display panel that is adapted to operate with a 
plurality of management consoles. Instead, Agnihotri teaches separate display 
interfaces for use with various management consoles. 

Agnihotri specifically teaches that the "plurality of console install DLLs 21 6A, 21 6B, 
and 21 6C" are used to provide the interfaces for installation. As shown in Agnihotri's 
Figure 3, these DLLs are each directed towards a different management console. 
Consequently, Agnihotri teaches that the display panels are coded in the separate 
DLLs and are not "adapted to operate with a plurality of the management consoles," 

Examiner respectfully disagrees. Looking to Fig. 3, it can be seen that the "plurality of 

console install DLLs" (216A-216B) represent an adaptation mechanism contained in the 

"Install framework 212" which is used to Integrate the component (applet)' (col. 5, lines 

8-10 'the component (applet) to be installed) including an associated 'image file for 

graphical representation on the console' (col. 5, lines 10-12). Thus it should be clear 

that Agnihotri discloses a display panel (the 'graphical representation' of a particular 

applet) that is adapted to operate with a plurality of management consoles (through the 

use of console install DLLs 216A-C). 

2c Dependent Claims 5, 12, and 19 

Beginning in the paragraph bridging pp. 13 and 14, Appellant states: 

Agnihotri does not teach or suggest the limitations of claims 5, 12, and 19. 

In the cited section, Agnihotri is discussing interface COM objects that are used to 
translate instructions from one console (the MConsole Interface) to other consoles. 
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Nowhere does Agnihotri teach or suggest "retrieving ... plug-in runtime algorithms" 
that correspond to one of the consoles, as taught and claimed by Appellants. 
Moreover, Agnihotri does not teach "compiling ... the generated console plug-in files 
... resulting in an executable ... adapted to interface with the management 
console..." Instead, as discussed above, Agnihotri is simply teaching use of a 
module that translates console instructions from one console to another console. 

In col. 6, lines 49-53 Agnihotri discloses "The MConsole Interface module 220 ... 

[provides] a comprehensive generic interface to existing Enterprise management 

consoles". This clearly discloses an executable entity adapted to interface with the 

management console. 

In col. 6, lines 53-61 Agnihotri discloses "COM objects ... for automating integration ... 
into existing Enterprise management consoles". This clearly discloses algorithms 
corresponding a console. 

Further it can be seen from Agnihotri's Fig. 4 that the 'MConsole' and 'COM objects' are 
linked thereby 'generating a plug-in code file 1 . Additionally such a step would first 
require that the objects (COM objects in particular) be retrieved from whatever storage 
medium they were residing on. Further, Fig. 4 shows that these objects are in DLL and 
COM formats, respectively, and thus must have been compiled to produce executable 
objects. 

2d. Dependent Claims 6. 13 and 20 

In the first full paragraph on pg. 15, Appellant states: 

The Final Office Action asserts that Agnihotri teaches Appellants' limitation of 
"copying the display panel files from the distribution medium to a nonvolatile storage 
device accessible by the computer system," citing col. 5, lines 15-18. However, this 
section of Agnihotri clearly only discusses installing the "applet" (code) and never 
teaches or suggests installing a separate display panel: 
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Examiner respectfully disagrees. In col. 5, lines 8-13 Agnihotri discloses that a file 
associated with each applet ('an install file for the ... applet') 'may contain ... an image 
file for graphical representation on the console'. Further this 'install file' is clearly 
included in the install package (The wizard ... may read an install file') and 
consequently would have been 'copied from the distribution medium to a nonvolatile 
storage device'. 

2e. Dependent Claims 7, 14 and 21 

In the paragraph bridging pp. 15 and 16 Appellant states: 

The Final Office Action contends that Appellants last limitation (displaying a display 
panel corresponding to one of the display panel files in response to the received 
selection) is taught by Agnihotri at col. 5, lines 10-12. however, the section of 
Agnihotri merely states that an "install file may contain a configuration file and an 
image file for graphical representation on the console." Importantly, neither this 
section, for anywhere else in Agnihotri, teach or suggest displaying a display panel 
that is separate and apart from the program code as taught and claimed by 
Appellants. 

The relevant passage of Agnihotri is reproduced below: 

The wizard application may read an install file for the component (applet) to be 
installed. The install file may contain a configuration file and an image file for 
graphical representation on the console. 

Appellant does not point out any distinction between the cited passage of Agnihotri and 

Appellant's claimed displaying a display panel ('an image file for graphical 

representation on the console') that is separate and apart from the program code ('an 

install file for the component (applet)'). 

Representing an image file on the console falls well within the scope of "displaying a 
display panel", and it is clear that 'an install file for a component is not the component it 
self and consequently is separate and apart from the component. Therefore Agnihotri's 
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disclosed 'image file' (col. 5, lines 10-12) reads on the claimed feature of 'a display 
panel that is separate and apart from the program code'. 

II. 35 U.S.C. 103, Alleged Obviousness 

Appellant's arguments on pp. 16-18 regarding the 103 obviousness rejection of claims 
2, 9, 16 and 22-24 rely on arguments made against the rejection of previous claims, 
which have been addressed above, and consequently are not addressed here. 
Further, Applicant has not argued why it would not have been obvious to combine the 
teachings of Agnihotri with those of the CIM specification, as presented in the rejections 
above. Accordingly this combination is considered proper. 
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(11) Evidence Appendix 

There is no additional evidence entered and relied upon in this appeal 



(12) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 



For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
Jason Mitchell 
3/30/06 
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Abstract 

The DMTF Common Information Model (CIM) is an approach to the management of 
systems and networks that applies the basic structuring and conceptualization techniques 
of the object-oriented paradigm. The approach uses a uniform modeling formalism that- 
together with the basic repertoire of object-oriented constructs — supports the cooperative 
development of an object-oriented schema across multiple organizations. 

A management schema is provided to establish a common conceptual framework at the 
level of a fundamental typology — both with respect to classification and association, and 
with respect to a basic set of classes intended to establish a common framework for a 
description of the managed environment. The management schema is divided into these 
conceptual layers: 

• Core model — an information model that captures notions that are applicable to all 
areas of management. 

• Common model — an information model that captures notions that are common to 
particular management areas, but independent of a particular technology or 
implementation. The common areas arc systems, applications, databases, networks 
and devices. The information mode! is specific enough to provide a basis for the 
development of management applications. This model provides a set of base classes 
for extension into the area of technology-specific schemas. The Core and Common 
models together are expressed as the CIM schema. 

• Extension schemas — represent technology-specific extensions of the Common 
model. These schemas are specific to environments, such as operating systems (for 
example, UNIX* or Microsoft Windows 1 ). 
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1 Introduction and Overview 



This section describes the many ways in which the Common Information Model (CIM) can be 
used. It provides a context in which the details described in the later chapters can be understood. 

Ideally, information used to perform tasks is organized or structured to allow disparate groups of 
people to use it. This can be accomplished by developing a model or representation of the details 
required by people working within a particular domain. Such an approach can be referred to as an 
information model. An information mode! requires a set of legal statement types or syntax to 
capture the representation, and a collection of actual expressions necessary to manage common 
aspects of the domain (in this case, complex computer systems). Because of the focus on common 
aspects, the DMTF refers to this information model as CIM, the Common Information Model. 

This document describes an object-oriented meta model based on the Unified Modeling Language 
(IFML). This model includes expressions for common elements that must be clearly presented to 
management applications (for example, object classes, properties, methods and associations). 
This document does not describe specific CIM implementations, APIs, or communication 
protocols - those topics will be addressed in a future version of the specification. For information 
on the current core and common schemas developed using this meta model, contact the 
Distributed Management Task Force. 

1.1 CIM Management Schema 

Management schemas are the building blocks for management platforms and management 
applications, such as device configuration, performance management, and change management. 
CIM is structured in such a way that the managed environment can be seen as a collection of 
interrelated systems, each of which is composed of a number of discrete elements. 

CIM supplies a set of classes with properties and associations that provide a well-understood 
conceptual framework within which it is possible to organize the available information about the 
managed environment. It is assumed that CIM will be clearly understood by any programmer 
required to write code that will operate against the object schema, or by any schema designer 
intending to make new information available within the managed environment. 

CIM itself is structured into these distinct layers: 

♦ Core model — an information model that captures notions that are applicable to all areas of 
management. 

• Common model — an information model that captures notions that are common to particular 
management areas, but independent of a particular technology or implementation. The 
common areas are systems, applications, networks and devices. The information model is 
specific enough to provide a basis for the development of management applications. This 
schema provides a set of base classes for extension into the area of technology-specific 
schemas. The Core and Common models together are referred to in this document as the CIM 
schema. 
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• Extension schemas — represent technology-specific extensions of the Common model. These 
schemas are specific to environments, such as operating systems (for example, UNIX or 
Microsoft Windows). 

L1J Core Model 

The Core model is a small set of classes, associations and properties that provide a basic 
vocabulary for analyzing and describing managed systems. The Core model represents a starting 
point for the analyst in determining how to extend the common schema. While it is possible that 
additional classes will be added to the Core model over time, major re-interpretations of the Core 
model classes are not anticipated. 

L1.2 Common Model 

The Common model is a basic set of classes that define various technology-independent areas. 
The areas are systems, applications, networks and devices. The classes, properties, associations 
and methods in the Common model are intended to provide a view of the area that is detailed 
enough to use as a basis for program design and, in some cases, implementation. Extensions are 
added below the Common model in platform-specific additions that supply concrete classes and 
implementations of the Common model classes. As the Common model is extended, it will offer 
a broader range of information. . 

7. 1.3 Extension Schema 

The Extension schemas are technology-specific extensions to the Common model. It is expected 
that the Common model will evolve as a result of the promotion of objects and properties defined 
in the Extension schemas. 

1.2 CIM Implementations 

CIM is a conceptual model that is not bound to a particular implementation. This allows it to be 
used to exchange management information in a variety of ways; four of these ways are illustrated 
in Figure l-l. It is possible to use these ways in combination within a management application. 
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